On the Purpose of Software Reuse

As modern software grows more and more complex, various techniques are invented or introduced to this field to increase productivity and reliability of software development. Software reuse plays an important role with respect to this goal. This essay tries to summarize popular techniques in software reuse field. Basing on a set of terminologies, we examine the nature of the techniques by clarifying the form and kernel logic of the reused assets, then identifying involved actors and activities. We believe this helps on both understanding the techniques and using or developing the techniques. 1. Background Software reuse has been practiced since programming began.[1] Software reuse’s purpose is to improve software productivity and quality by utilizing existed and proven software pieces when develop the new software. It is of more and more interests because people always want to build systems that are bigger and more complex, but still reliable while costs even shorter time. There have been various discussions in literature about software reuse from both the technical perspectives and the organizational perspectives, from mechanisms to methodologies, from programming language to tools. Those divergent perspectives at times blur software reuse outlines. What is the difference and what is the relationship between them? In this essay, we reviewed some popular techniques in this area, and tried to find out some common parts by observing in the same perspectives. This essay will be organized as below. Section two introduces the terminologies and the theme with which we review the techniques. Section three reviews popularly used techniques in software reuse field. Section four concludes this essay. 2. Introduction 2.1 Scope We will emulate some popularly used concepts related to software reuse, which includes mechanisms, techniques, methodologies and etc. There are overlaps and collaborations between these concepts when they are used in both researching and industry. We will call them techniques for simple in this essay. We do not intend to make the enumeration exhausted, or intend to clarify their definitions. Instead, we aim to examine and understand their essence in a uniformed way. That is, keep what is expected to be reused in head, and try to identify who is involved and what kind of activities shall get benefits from the techniques. We believe this is helpful to not only understanding the technique, but also working to improve the technique and the application of the technique. 2.2 Terminologies We will use the following unified terminologies in this essay: 2.2.1 Reuse, Reuse Asset, Reuse Activities, Reuse Technique Reuse means software reuse, which means, utilizing useful part in existed software to construct new software. Reuse Asset: The part extracted from existed software that will be used when constructs new software. Reuse Activities involves all activities aiming to the development of the Reuse Assets, or to the usage of the Reuse Assets. There is one or more Actors involved in one Reuse Activity. Reuse Technique involves all related technique, which Reuse Activities can get benefits from, especially, includes the techniques to develop reuse assets, and the techniques to use reuse assets. One specific Reuse Technique can involve both kinds of techniques. 2.2.2 For Reuse and With Reuse: ’For reuse’ and ’with reuse’ are used in [2] to refer to different technical aspects of reuse. Here we change them a bit to indicate the category of reuse activities: ‘For reuse’ means the activity is about developing Reuse Assets, packaging the Reuse Assets, and everything that to ease the usage of Reuse Assets later. ‘With reuse’ means the activity is about using the Reuse Assets to develop new software. 2.2.3 Design Reuse and Code(implementation) Reuse: This is to indicate the deployment format/form of Reuse Asset. The reuse asset can be a piece of source code written in a specified programming language, or in binary organized with a platform specification. In such cases, the reuse asset is on hand to construct new software. However, there are other cases. Sometimes we may want to reuse some ‘ideas’. We want to reuse these ideas in different context, in programs that are written in different languages, above different platforms. These ‘ideas’ are common in a higher abstraction level between the problem space to the solution space, thus we commonly express them with one modeling language or even less formally, with natural language. Design Reuse has advantages over Code reuse. It can be applied in more contexts and so is more common. Also, it is applied earlier in the development process, and so can have a larger impact on a project. But most design reuse is informal, and happens through using experienced developers. There is no standard design notation and there are no standard catalogs of designs to reuse. A single company can standardize, and some do, but this will not lead to industry-wide reuse. In summary, design reuse is more abstract than code reuse, and thus can be used in wider contexts. But on the other hand, code reuse is more concrete, and makes it easier to construct new software in suitable contexts. When code reuse is the case, the reuse assets are reused by black-box way (through well-defined interface, commonly in binary) or by white-box way (in source code). 2.2.4 Frame Reuse and Ware Reuse: We use this to address the kernel logic of reuse asset. It may be easier to understand if we use ‘framework’ and ‘component’. Different terms are used to avoid confusion because ‘framework’ and ‘component’ are all named as specific reuse techniques as I will review in next section. It could be more accurate to call them ’interface user’ and ‘interface implementer’. Here interface corresponds to the Reuse Asset. Interface user defines interfaces, and integrates interface implementer. But be aware that on the other hand, interface user itself may implements a higher level interface thus is an interface implementer to a higher level interface user. ‘Frame reuse’ will be used to indicate that the interfaces, the parts using the interfaces are what we want to reuse. While ‘Ware reuse’ indicates that the interfaces, the parts implementing the interfaces are what we want to reuse. Thus both ‘Frame’ and ‘Ware’ are relative to the interfaces. 2.3 Review Theme We will then review popular reuse techniques by considering the following questions:  What is the Reuse Assets when the technique is applied?  What is the deployment format of the Reuse Assets (Design or Code), and what is the valuable kernel logic of the Reuse Assets (Frame or Ware).  What are the main Reuse Activities involved in two reuse categories (For Reuse and With Reuse) individually.  What kinds of actors may be involved in? 3. Techniques Review 3.1 Programming Language Mechanisms The evolution of programming languages is tightly coupled with reuse in two important ways. First, programming languages have evolved to allow developers to use ever larger grained programming constructs, from ones and zeroes to assembly statements, subroutines, modules, classes, frameworks, etc. Second, programming languages have evolved to be closer to human language, more domain focused, and therefore easier to use.[1] Programming language mechanisms are the basis of all other Reuse techniques, because when a new software is constructed, it is always implemented in one or more specific programming languages. As indicates in [3], Encapsulation of procedures, macros and libraries has been exploited for many years to enhance the reusability of software. Object-oriented techniques achieve further reusability through the encapsulation of programs and data. Here we will take Object-oriented programming languages for example, and review related mechanisms which Reuse could get benefits from. With different benefits that can be gained in different mechanisms, the Reuse Assets are always in source code format or in binary (Code Reuse). Frame Reuse Ware Reuse